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@ A method of data retrieval reduces the num-- 
ber of Instrumentation message flows in a Sim- 
ple Network Management Protocol (SNMP) 
device (38). The method uses * look-ahead" 
algorithms whereby data items which have not 
yet been requested by the Agent (36) (but are 
expected to be) are retrieved from. Instrumen- 
tation (42). The method comprises the step of 
retrieving from the Instrumentation an entire 
row of data from an SNMP table whenever a 
GetRequest or GetNextRequest Protocol Data 
Unit (PDU) is issued by the Manager (22) to the 
Agent. A SubAgent (40) saves this row in antici- 
pation of a. subsequent request for another 
column in this same row thereby eliminating the 
need for further Instrumentation message flows 
for further data retrieval from this row. 
Whenever a new GetRequest is issued by the 
Manager, a new set of data is retrieved from the 
Instrumentation. The method further comprises 
the step of retrieving the next subsequent data 
item in response to a GetNextRequest against 
the last row in a given column thereby eliminat- 
ing the need for a second message exchange at 
an "end of column " condition. 
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The present invention relates to network man- 
agement using the Simple Network Management 
Protocol (SNMP) and t more particularly, to a method 
of reducing the number of message flows to and from 
an Instrumentation in an SNMP device. 

Data communication has become a fundamental 
part of computing. World-wide networks gather data 
about such diverse subjects as atmospheric condi- 
tions, crop production, and airline traffic. These net- 
works evolved as independent entities without the 
ability, or, until recently, the need, to interconnect 
with one another. New technologies, generically 
named "internetworking", have emerged making it 
possible to interconnect many disparate physical net- 
works and make them function as a coordinated unit. 
Using internetworking technologies, a host, for exam- 
ple, on one network, may traverse multiple networks 
and communicate with another host on a different 
network. 

The size of an "internet", or group of interconnect- 
ed networks, can vary quite significantly. For in- 
stance, the resulting network may be enormously 
large, such as the nation-wide DARPA (Defense Ad- 
vanced Research Projects Agency)/NSF (National 
Science Foundation) Internet which connects most 
major research institutions, including universities, 
corporate and government labs. Conversely, the net- 
work may be relatively small, comprising only a single 
corporation's individual local area networks (LANs). 

No matter the size of the network, it is clear that 
the task of effectively managing the resulting inter- 
connected network is quite important and has been 
given a great deal of attention in the networking com- 
munity. In managing a network, a network manager 
must keep track of the devices on the networks, mon- 
itor the network's performance and load, and diag- 
nose and correct any problems. 

While products that manage homogeneous net- 
works have been available, managing heterogene- 
ous networks is more complex and, until recently, no 
generally accepted heterogeneous network manage- 
ment standard existed. The Simple Network Manage- 
ment Protocol (SNMP), which originated as a means 
for managing the TCP/IP (Transmission Control Pro- 
tocol/Internet Protocol) and Ethernet networks, has 
broadened rapidly since its monitoring and control 
transactions are completely independent of TCP/IP 
and Ethernet. SNMP only requires datagram trans- 
port mechanisms to operate. 

Using SNMP, network administrators can ad- 
dress queries and commands to network nodes and 
devices. SNMP monitors network performance and 
status; controls operational parameters; and reports, 
analyzes and isolates these faults. The protocol ac- 
complishes these functions by transporting manage- 
ment information between "Managers" and "Agents". 

SNMP defines the following three basic compo- 
nents: 



1. An Agent, a component housed within a man- 
aged network device such as a host, gateway, or 
terminal server. Each Agent stores management 
data and responds to the Manager's requests for 

5 this data, and may send a 'TRAP", a special un- 

solicited SNMP command, to the Manager after 
sensing a prespecified condition. 

2. A Manager, a component housed within a Net- 
work Management Station. The Manager quer- 

10 ies/controls Agents using various SNMP com- 

mands. 

3. AManagement Information Base (MIB), a man- 
aged object data-base, accessible to Agents and 
manipulated via SNMP for network management 

15 application. 

To carry out the Agent's and Manager's duties, 
SNMP specifies five types of commands or verbs, 
called Protocol Data Units (PDUs): GetRequest, Get- 
NextRequest, SetRequest, GetResponse and Trap. 
20 (The SetRequest and Trap PDUs are unrelated to the 
present application and will not be discussed.) Agents 
inspect and retrieve the specified table values after 
receiving either a GetRequest or a GetNextRequest 
PDU from a Manager. Managers use GetRequest for 
25 retrieving single values. The GetNextRequest is is- 
sued by the Manager to begin a primitive block trans- 
fer and the Agent returns the selected data with a Ge- 
tResponse verb. 

Conceptually, SNMP employs tables to store the 
30 information in the MIB. These tables consist of rows 
and columns. Figure 1 illustrates a typical SNMP ta- 
ble. Columns are attributes, or object types in SNMP 
terms, that characterize the resources. Each row rep- 
resents an instance of the resource. An SNMPGetRe- 
35 quest or GetNextRequest of a single object allows a 
manager to retrieve an instance of the object. The 
SNMP GetRequest and GetNextRequest also allow 
the retrieval of a set of objects with one request. Al- 
though, SNMP does not restrict what objects should 
40 be requested in one PDU, most managers will re- 
trieve information (either whole or a subset) from a 
row. The Agent treats each object in the PDU as a 
separate request and passes it to the SubAgent This 
is demonstrated in Figure 2 as discussed below. 
45 Figure 2 illustrates a system 20 conforming to 

SNMP. In order to assist in managing and organizing 
the vast amounts of data which need to be collected 
and maintained for access by the Manager 22 in the 
Network Management Station 24, the Agent 26 of the 
so managed network device 28 may use one or more 
SubAgents (one SubAgent 30 shown) for manipulat- 
ing the data items in the various tables. Each Sub- 
Agent may be responsible for a particular table or set 
of tables. In order to access the particular tables, the 
55 SubAgents issue commands to the managed network 
device Instrumentation 32, which actually maintains 
the physical data items. 

In order to retrieve ail the data items in a given 
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row, the Manager would issue a GetRequest or Get- 
NextRequest to the Agent. The command would spec- 
ify the specific data location, i.e., (row 1,col. 1), (row 
1 . col. 2), . . .(row m, col. n) of the desired data items 
so that one PDU is issued for multiple data items. The 
Agentthen individually passes a request for each data 
item to the SubAgent which, in turn, passes it to the 
Instrumentation. The Instrumentation responds for 
each request to the requesting SubAgent which, in 
turn, responds to the Agent The Agent subsequently 
collects all the results and responds to the Manager 
the requested data item values, normally with a single 
GetResponse PDU. 

This is shown in Figure 2. Manager 22 issues a 
single GetRequest PDU (GetReq 1) for the desired 
data items ((1, 1), (1, 2), (1, 3)). (Alternatively, the 
Manager may issue multiple PDUs specifying the de- 
sired data items.) Agent 26 receives this PDU and 
sends a first request for the first data item (Req 1 (1 , 
1)) to SubAgent 30, which, in turn, forwards it to In- 
strumentation 32. Instrumentation retrieves the data 
item from the table and sends it to SubAgent 30 (Resp 
1 (1 , 1)), which forwards it to Agent 26. Agent 26 then 
forwards the next request (Req 2 (1 , 2)), and likewise 
Req 3 (1 , 3), to the SubAgent 30 for the same retrieval 
process. When Agent 26 has received all of the data 
items, it sends them to Manager 22 via a single Ge- 
tResponse PDU (GetResp 1 (1, 1), (1,2), (1. 3)). 

This one-for-one exchange between the Sub- 
Agent and the Instrumentation is costly in terms of 
processing time. Each request issued by the Sub- 
Agent to the Instrumentation consumes processing 
time which the Instrumentation would otherwise be 
devoting to another task, such as routing incoming 
datagrams, if the managed network device was a 
router, for example. If, for instance, the Manager wish- 
es to retrieve a network device status table consisting 
of 1000 rows and 50 columns in order to provide a 
. graphical user interface depicting a network map, the 
Instrumentation would be required to process 50,000 
information requests. 

A large number of exchanges between the Sub- 
Agent and the Instrumentation severely degrades the 
performance of the managed network device. During 
the time the Instrumentation is processing these in- 
formation requests, in the case where the managed 
network device is a router, network traff ic can not be 
routed. Thus, the more the device is managed using 
traditional methods, the less it is able to perform its 
primary routing/networking functions. 

Additionally, when a single Manager PDU Re- 
quest causes a large number of individual messages 
to be exchanged between the SubAgent and the In- 
strumentation, a great deal of time may elapse be- 
tween the first message exchange and the last. Dur- 
ing that time, conditions which the Instrumentation is 
monitoring may change. This is a problem as the Man- 
ager cannot be ensured that it has obtained a "snap- 



shot 0 of the condition at one instant in time as the con- 
dition may or may not be dynamic. 

Another problem with this prior art SNMP data re- 
trieval system is that when a GetNextRequest is is- 
5 sued to the Instrumentation when at the end of a col- 
umn of data, i.e., at the last row in the column, a "no- 
SuchName" response is generated. A second Get- 
NextRequest must be issued so that the first data 
item of the following column may be retrieved. In other 
10 words, where a table has °m n rows and "n" columns, 
a GetNextRequest (Row m, Col. x) where V is any 
column number no greater than "n", a noSuchName 
response is sent back to the SubAgent Another Get- 
NextRequest (0, Col. x+1) must be issued to Instru- 
15 mentation for retrieving the data item located at (Row 
1, Col. x+1). This additional message exchange be- 
tween the Instrumentation and the SubAgent exacer- 
bates the problem of high numbers of processing re- 
quests further distracting the Instrumentation from 
20 its primary responsibility. 

Figure 3 illustrates a prior art SNMP retrieval sys- 
tem at the other extreme. Manager 22 issues a Ge- 
tRequest PDU (GetReql (1,1), (1,2), (1; 3)) to Agent 
26 which sends individual requests for each data item 
25 to SubAgent 31. SubAgent 31 issues a generic Req 
command to Instrumentation 33 which responds by 
sending its entire database (All Rows, All Cols.) to 
SubAgent 31. SubAgent 31 sends the individual data 
items back to Agent 26 in response to requests which 
30 collects them for forwarding to Manager 22. 

While reducing the individual Sub Agent- Instru- 
mentation message flows, this method of retrieving 
data from the Instrumentation is inefficient for a num- 
ber of reasons. First, by the Instrumentation doing a 
35 complete "data dump" to the SubAgent whenever 
there is a data item request, the SubAgent is required 
to provide a great deal of internal storage. Duplicate 
copies of the entire database are maintained which is 
wasteful as the database may be huge. Second, often 
40 times, the data maintained by the Instrumentation is 
dynamic so that subsequent GetRequests from the 
Manager will result in inaccurate data retrieval from 
the SubAgent as the data stored therein is untimely. 
Finally, frequently, SubAgents protect against old, in- 
45 accurate data by dumping its stored data after a pre- 
determined period of time. This merely causes further 
complete Instrumentation data dumps whenever a 
data item is requested. 

50 SUMMARY OF THE INVENTION 

The invention relates to a method and apparatus 
for retreiving data items in a Simple Network Manage- 
ment Protocol (SNMP) managed device which reduce 
55 the number of instrumentation message flow. The 
method, according to the invention, is for retrieving 
data items from a table in the SNMP managed device 
means including an agent or an agent and a sub- 
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agent, and an instrumentation, said instrumentation 
having at least one table having a plurality of rows and 
a plurality of columns, said at least one table having 
plurality of data items in corresponding table locations 
defined by said plurality of rows and said plurality of 
columns, said method characterized in that it includes 
the following steps: 

a) said means receiving a request for retrieving at 
least one data item from a table location defined 
by one of said rows and at least one of said col- 
umns; 

b) said means requesting said instrumentation to 
retrieve all of said data items from said table in 
said one row; 

c) said means receiving from said instrumenta- 
tion all of said data items in said one row; 

d) said means storing said data items from said 
one row in an internal storage area; and 

e) said means responding with said at least one 
data item from said table location defined by said 
one row and said at least one column. 

BRIEF DESCRIPTION OF THE DRAWINGS 

While the technical description concludes with 
claims particularly pointing out and distinctly claiming 
that which is regarded as the invention, details of a 
preferred embodiment of the invention may be more 
readily ascertained from the following technical de- 
scription when read in conjunction with the accompa- 
nying drawings, where: 

Fig. 1 is an illustration of table which may be used 
in a Simple Network Management Protocol (SNMP) _ 

managed device. _ _. _. 

Fig. 2 is a block diagram illustrating the message 
exchanges occurring between a Manager, an Agent, 
a SubAgent and an Instrumentation during a tradi- 
tional SNMP block transfer function. 

Fig. 3 is a block diagram of another prior art 
SNMP data retrieval system illustrating the message 
exchanges occurring between a Manager, an Agent, 
a SubAgent and an Instrumentation during an SNMP 
block transfer. 

Fig. 4 is a block diagram illustrating the message 
exchanges occurring between a Manager, an Agent, 
a SubAgent and an Instrumentation during an SNMP 
data retrieval process of the present invention. 

Fig. 5 is a block diagram illustrating the message 
exchanges occurring between a Manager, an Agent, 
a SubAgent and an Instrumentation during another 
SNMP data retrieval process of the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

The method of the present invention is utilized in 
a system conforming to the Simple Network Manage- 
ment Protocol (SNMP). By using "look-ahead" algo- 



rithms, the method reduces th number of exchanged 
messages between the Instrumentation portion of 
the managed network device and the SubAgent por- 
tion of the managed network device during a data re- 
5 trieval process. In particular, the method of the pres- 
ent invention takes advantage of the premise that, 
during the process of managing a network, many 
times the Manager will need to analyze groups of re- 
lated data items from tables in the managed network 
10 device, rather than individual, isolated data items. For 
example, where the table is maintained with data 
items indicating errors or faults occurring with relation 
to the managed network device, i.e., a problem deter- 
mination table, the Manager will need to analyze all 
15 or most of the fault indicating data in order to det r- 
mine what is causing the various problems. So, where 
the Manager requests the retrieval of one data item, 
it is expected that the Manager will soon be request- 
ing for retrieval of related data items. These related 
20 data items are normally grouped together in rows. 

Moreover, data maintained by the Instrumenta- 
tion is frequently dynamic in nature. The data retriev- 
al system must, therefore, consider this so that accu- 
rate data is returned to the Manager. Finally, a Man- 
25 ager often needs a "snapshot", or a picture at one 
point in time, of a group of related items which it re- 
quests using a single GetRequest or GetNextRe- 
quest PDU. The present invention accounts for each 
of these considerations by providing a unique system 
30 and method of retrieving data from Instrumentation 
using a reduced number of message flows while pro- 
viding accurate and timely data for the Manager. 
Figure 4 is a block diagram of an SNMP system 
... _ 34 illustrating the message exchanges occurring be- 
35 tween a Manager 22 in a Network Management Sta- 
tion 24, and Agent 36, a SubAgent 40 and Instrumen- 
tation 42 of the managed network device 38, during 
an SNMP data retrieval process of the present inven- 
tion. This is illustrated as the preferred embodiment 
40 of the present invention although other equivalent 
configurations can work equally as well. For example, 
a SubAgent 40 is shown as acting as an interface be- 
tween the Agent 36 and the Instrumentation 42. The 
SubAgent is unnecessary but rather merely prefer- 
45 red. The method and system of the present invention 
focus on the reduction of Instrumentation message 
flows - whether the Agent directly corresponds with 
the Instrumentation or has the SubAgent as a liaison 
is immaterial. 

50 As can be seen, the Manager 22 issues a single 

GetRequest Protocol Data Unit (PDU) for three data 
items ((1 , 1 ), (1 , 2), (1 , 3)) to the Agent 36 of the man- 
aged network device 38. Agent 36 forwards the re- 
quest for the first data item (Req 1 (1 , 1 )) to SubAgent 

55 40. SubAgent 40, instead of merely forwarding the 
identical request to Instrumentation 42, issues a re- 
quest for retrieving the entire contents of row 1 (Req 
1 (1, All Cols)). Instrumentation retrieves the contents 
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of row 1 and sends them to SubAgent 40 (Resp 1 (1 , 
All Cols)). 

SubAgent 40 receives the contents of row 1 and 
stores them in an internal storage area which it main- 
tains for future use. SubAgent 40 then forwards to 
Agent 36 (Resp 1 (1, 1)) the contents of the table lo- 
cation def ined by row 1, column 1. 

Agent 36 forwards the request for the next data 
item to SubAgent 40 (Req 2 (1 , 2)). SubAgent 40, hav- 
ing stored the contents of row 1 in its internal storage 
area, retrieves the requested data items and returns 
it to Agent 36 (Resp 2 (1 , 2)). The third data item re- 
quest from the Agent 36 is handled in the same way 
by the SubAgent until a data item from another row 
is requested by a GetRequest. Once Agent 36 has re- 
ceived all responses, Agent 36, in turn forwards them 
in a single GetResponse PDU (GetResp 1 (1, 1), (1, 
2), (1,3)) to Manager 22. 

As can clearly be seen, the method employed by 
the SubAgent significantly reduces the message flow 
to and from the Instrumentation when a series of data 
items are requested by the Manager during a single 
PDU. This frees up processing time for the Instru- 
mentation to provide its primary services, such as 
protocol routing in the case of a router. When the Man- 
ager issues a new GetRequest or GetNextRequest 
PDU, a new series of data items are retrieved from 
the Instrumentation so that a "snapshot" of a partic- 
ular condition may be obtained and so that the data 
items sent to the Agent are timely and accurate. 

In the case where a Manager issues a series of 
GetNextRequests to the Agent and spill-over occurs, 
i.e., an end of column is reached, the method and sys- 
tem of the present further reduces messageflows be- 
tween the SubAgent and the Instrumentation as com- 
pared to traditional methods and systems. This is 
shown in Figure 5. Initially, the Manager requests the 
data item located in the last row (row m) of any column 
(column 1 is used as an example) using a GetNextRe- 
quest with the data item location specified (GetNext 
(m, 1)). Agent 36 forwards the GetNextRequest to 
SubAgent 40. SubAgent 40 issues a GetNextRequest 
for the entire next row (GetNext (m, All Cols.)) to In- 
strumentation 42. Because the last row has been 
reached, there is not a "next row" to be retrieved by 
Instrumentation 42. Instrumentation 42 returns to the 
SubAgent 40 a noSuchName response (as it normally 
does when reaching the end of a column). But, in ad- 
dition, it returns the data items of the first row (Resp 
(1, All Cols.)) along with the noSuchName response. 
This allows SubAgent 40 to select the second column 
of the first row and forward that value to Agent 36 us- 
ing Resp (1 , 2) which in turn sends the requested val- 
ue to Manager 22. This eliminates the traditionally 
necessary step of the SubAgent forwarding the no- 
SuchName response to the Agent, requiring addition- 
al message flows between the SubAgent/lnstrumen- 
tation. 



As can be seen, this portion of the method em- 
ployed by the SubAgentf urther reduces the message 
flow between the SubAgent and the Instrumentation 
when the series of data items requested by the Man- 
5 ager spi lis over into the next column. This frees up ad- 
ditional processing time for the Instrumentation to 
provide its primary services. 

Thus, it can be seen that the method and system 
of the present invention reduces the number of Instru- 
w mentation flows in a Simple Network Management 
Protocol (SNMP) device. The method and system use 
"look- ahead" algorithms whereby data items which 
have not yet been requested by the Agent (but are ex- 
pected to be) are retrieved from Instrumentation. The 
15 method and system free up Instrumentation process- 
ing time by reducing flows. Further, the method and 
system can be easily expanded to return multiple 
rows as opposed to returning a single row which may 
result in an even greater reduction in flows to and 
20 from the Instrumentation. The number of rows re- 
turned would depend directly upon the Manager's 
GetRequest PDUs. For each new GetRequest or Get- 
NextRequest PDU from the Manager, a new set of 
data is received from the instrumentation. Where 
25 data items from different rows are requested from a 
single GetRequest (or GetNextRequest) PDU, multi- 
ple rows containing the data items may be returned 
from the Instrumentation so that an accurate "snap- 
shot" may be taken by the Manager. 
30 While the invention has been particularly shown 

and described with reference to preferred embodi- 
ments thereof, it will be understood by those skilled 
in the art that various other changes in form and detail 

may be made without departing from the scope of the 

35 "invention. 



Claims 

40 1 . A method for retreiving data items from a table in 
a Simple Network Management Protocol (SNMP) 
device comprising means (36, 40) including an 
agent or an agent and a subagent, and an instru- 
mentation, said instrumentation having at least 
45 one table having a plurality of rows and a plurality 

of columns, said at least one table having plurality 
of data items in corresponding table locations de- 
fined by said plurality of rows and said plurality of 
columns, said method characterized in that it in- 
50 eludes the following steps: 

a. said means receiving a request for retriev- 
ing at least one data item from a table location 
defined by one of said rows and at least one 
of said columns; 
55 b. said means requesting said instrumenta- 

tion to retrieve all of said data items from said 
table in said one row; 

c. said means receiving from said instrumen- 
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tation all of said data items in said one row; 

d. said means storing said data items from 
said one row in an internal storage area; and 

e. said means responding with said at least 

one data item from said table location defined 5 
by said one row and said at least one column. 

2. The method according to Claim 1 wherein said 
means (36, 40) are an agent (36). 

10 

3. The method according to Claim 1, in which said 
means (36, 40) include an agent (36) and a sub- 
agent (40), said method being characterized in 
that: 

• step a is performed by said agent; said 15 
method being further characterized in that 

it includes, between step a and step b the 
sub-step of: 

• said agent sending a request to said sub- 
agent for retrieving one data item from a ta- 20 
ble location defined by said one row and 

one of said at least one column; 

• step b is performed by said subagent; 

• step c is performed by said subagent; 

• step d is performed by said subagent; said 25 
method being further characterized in that 

it includes, between step 4 and step 5 the 
sub-step of: 

• said subagent sending to said agent said 

one data item from said table location de- 30 
fined by said one row and said one column; 

• step e is performed by said agent. 

4. The method according to Claim 3 further com- 

prising the following steps: 35 

• said subagent receiving from said agent a 
second request for retrieving a data item 
from a table location defined by said one 
row and another of said columns 

• said agent retrieving from said subagent in- 40 
ternal storage area said data item from said 
table location defined by said first row and 
said another column; 

• said subagent sending to said agent said 
data item from said table location defined 45 
by said first row and said another column. 

5. The method according to Claim 2 or Claim 4, said 
one at least table having first through last rows 
and first through last columns, said method fur- so 
ther comprising for said agent (Claim 2) or said 
subagent (Claim 4) the following steps: 

• receiving a request for retrieving the next 
data item following the data item in a table 
location defined by one of said columns and 55 
said last row; 

• requesting said instrumentation to retrieve 
the data items in the next row; 



• receiving from said instrumentation the 
data items in said first row; 

• responding by the data item in the table lo- 
cation defined by said first row and the next 
column. 

6. ASimple Network Management Protocol (SNMP) 
device comprising an agent and an instrumenta- 
tion, said instrumentation having at least one ta- 
ble having a plurality of rows and a plurality of col- 
umns, said at least one table having plurality of 
data items in corresponding table locations de- 
fined by said plurality of rows and said plurality of 
columns, said agent for retrieving said data items 
from said table characterized by: 

• means for receiving a request for retrieving 
at least one data item from a table location 
defined by a first of said plurality of rows 
and at least one of said columns; 

• means for requesting said instrumentation 
to retrieve all of said data items from said ta- 
ble in said first row; 

• means for receiving from said instrumenta- 
tion all of said data items in said first row: 

• an internal storage area for storing said 
data items from said first row; and 

• means for sending said at least one data 
item from said table location defined by 
said first row and said at least one column. 

7. A device according to Claim 6, characterized by 
a subagent between said agent and said instru- 
mentation, said subagent corresponding with in- 
strumentation, and comprising the following 
means: 

• means for receiving a request from said 
agent for retrieving a data item from a table 
location defined by a first of said plurality of 
rows and one of said columns; 

• means for requesting said instrumentation 
to retrieve all of said data items from said ta- 
ble in said first row; 

• means for receiving from said instrumenta- 
tion ail of said data items in said first row; 

• an internal storage area for storing said 
data items from said first row; and 

• means for sending to said agent said data 
item from said table location defined by 
said first row and said one column. 

8. A device, according to Claim 6 characterized by 
said subagent comprising the following means: 

• means for receiving from said agent a sec- 
ond request for retrieving a data item from 
a table location defined by said first row and 
another of said columns; 

• means for retrieving from said subagent in- 
ternal storage area said data item from said 
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table location defined by said first row and 
said another column; 

• and means for sending to said agent said 
data item from said table location defined 

by said first row and said another column. 5 

9. A device, according to Claim 8, said one at least 
table having first through last rows and first 
through last columns, said device characterized 
by said subagent comprising the following 10 
means: 

• means for receiving a request for retrieving 
a data item from a table location defined by 
said last row and one of said columns; 

• means for responding by said data item 15 
from said table location defined by said last 

row and said one column; 

• means for receiving a request for retrieving 
the next data item; 

• means for requesting said instrumentation 20 
to retrieve the data items in the next row; 

• means for receiving from said instrumenta- 
tion the data items in the first row; and 

• means for responding by said data item 
from said table location defined by said first 25 

- row and said following column. 

10. A device according to Claim 8, wherein said de- 
vice is a router. 
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strumentation an entire row of data from an SNMP table 
whenever a GetRequest or GetNextRequest Protocol 
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Agent. A SubAgent (40) saves this row in anticipation of 
a subsequent request for another column in this same 
row thereby eliminating the need for further Instrumen- 
tation message flows for further data retrieval from this 
row. Whenever a new GetRequest is issued by the Man- 
ager, a new set of data is retrieved from the Instrumen- 
tation. The method further comprises the step of retriev- 
ing the next subsequent data item in response to a Get- 
NextRequest against the last row in a given column 
thereby eliminating the need for a second message ex- 
change at an "end of column 0 condition. 




5; 



Printed by Jouve (FR). 13 me Satni-Dents 75001 PARIS 



EP 0 621 705 A3 



j) 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 94 48 0010 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



Relevant 
to daun 



CLASSIFICATION OF THE 
APPLICATION qnt.Cl.5) 



THE SIMPLE BOOK AN INTRODUCTION TO 

MANAGEMENT OF TCP/ IP-BASED INTERNETS , 

ENGLEW00D CLIFFS, US, 

pages 131-158, 

M.T:R0SE 'Mechanism: SNMP' 

* paragraph 5.3.1 * 

C0NF- NOMS '92. NETWORKS WITHOUT BOUNDS. 
IEEE 1992 NETWORK OPERATIONS AND 
MANAGEMENT SYMPOSIUM , 
vol. 2, 1992 MEMPHIS, US, 
pages 254-265, XP 000344700 
S. RABIE ET AL. 'An integrated 
architecture for LAN/WAN Management 1 

* page 257 * 

* page 261 - page 262 * 
Figures 

IEEE GLOBAL TELECOMMUNICATIONS CONFERENCE, 
vol. 2, 6 December 1992 ORLANDO, US, XP 
000357707 

N. AG0ULMINE ET AL. 'A System 
Architecture for updating management 
information in heterogeneous networks 1 

* paragraph 3 * 



-10 



H04L12/24 
H04L29/06 



,6,10 



1-10 



TECHNICAL FIELDS 
SEARCHED (Int.Cl.5) 



H04L 



The present search report has been drawn up for all claims 



Placi of uack 

THE HAGUE 



D*e of CMrptetloa of Ifcc a*«k 

28 November 1995 



Staessen, B 



CATEGORY OF CITED DOCUMENTS 

X ; particularly relevant if taken alone 

Y : particularly relevant if combined with another 

document of the same category 
A : technological background 
O : non-written disclosure 
P : intern ediat* document 



T : theory or principle underlying the invention 
E : earlier patent document, but published on, or 

after the Tiling date 
D : document cited In the application 
L : document cited for other reasons 

& : member of the same patent family, corresponding 
document 



2 



